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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 
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Scope 



The present document forms the baseline specification for the provision of the DVB-S2 adaptive coding and modulation 
(DVB-S2 ACM) for GEO satellite interactive networks with dialup return channel terminals. It facilitates the use of 
such terminals for individual or collective communications in a domestic environment. It also supports the connection 
of such terminals with in-house satellite forward link and return channel telephone networks. The present document 
may be applied to all frequency bands allocated to GEO satellite services. The DVB-S2 standard is for forward link 
transmission. DVB-S2 is the second generation standard for satellite transmission, which provides higher power and 
bandwidth efficiency as well as adaptive coding and modulation. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
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• 



• 



• 
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[3] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio: Systems". 

[4] IEEE 802.3: "Information technology - Telecommunications and information exchange between 

systems - Local and metropolitan area networks - Specific requirements - 

Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and 
Physical Layer Specifications". 

[5] ETSI TR 102 376: "Digital Video Broadcasting (DVB); User guidelines for the second generation 

system for Broadcasting, Interactive Services, News Gathering and other broadband satellite 
applications (DVB-S2)". 

[6] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[7] ISO/IEC 13818-6: "Information technology - Generic coding of moving pictures and associated 

audio information - Part 6: Extensions for Digital Storage Media Command and Control 
(DSM-CC)". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACM Adaptive Coding and Modulation 

ACM_ACK ACM DVB-S2 ACKnowledgement of ACM_RQ 

ACM_CAP ACM DVB-S2 CAPabilities List 

ACM_RQ ACM DVB-S2 REQuest for MODCOD change 
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CNI Carrier to Noise Interference 

DVB Digital Video Broadcasting 

DVB-S2 DVB-S system generation as specified in EN 302 307 [1] 

GS Generic Stream 

GW GateWay at hub station 

IP Internet Protocol 

ISI Input Stream Identifier 

ISP Internet Service Provider (Terrestrial) 

MPEG-2 Motion Picture Experts Group version 2 

MSB Most Significant Bit 

PLFrame Physical Later Frame for DVB-S2 

PPP Point to Point Protocol 

ST Satellite (receiving) Terminal 

TBD To Be Determined 

TS Transport Stream 

UDP Unicast Datagram Packet 



4 System description 

4.1 Block description ACM system 

Figure 1 shows the scheme of a generic ACM satellite link from the DVB-S2 User Guideline (see TR 102 376 [5]), 
composed by the Gateway (GW), which includes the ACM DVB-S2 modulator, the Satellite, the Satellite (receiving) 
Terminal (ST) connected to the GW via a return channel. In the present document the return channel is a dial-up 
system. 
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NOTE: Source rate control may be directly applied to source(s) or locally at the GTW inputor via network traffic 
control. 

Figure 1 : Block diagram of a DVB-S2 ACM link 

The system is to be used for ACM control messages as per the DVB-S2 system standards [1]. The High bit-rate forward 
link will transport both MPEG2 Private Sections for physical layer ACM signalling and some IP encapsulation method 
that may have ACM control messages plus IP traffic. 
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4.2 Block description satellite terminal 

For discussion purposes the Satellite Terminal will consist of three block parts; the Receiver, The User PC, and the 
Modem. The Receiver functionality should be to process information in the Forward Link and forward onto the User 
PC. The User PC functionality is to handle IP Traffic but more importantly to ensure the Receiver is optimally tuned 
(reading CNI and adjusting ISI/MODCOD) to receive traffic by the use of control messages between the User PC and 
Receiver. Definitions of messaging between the User PC and Receiver are out of scope of the present document and 
Vendor Specific. The Modem is to send and receive IP traffic via the Return Channel. The Satellite Terminal can 
consist of one to three individual units and are split in three pieces for clarification. 




Receiver 




IP 1 
Satellite 
Interface 



User PC 



IP 2 

Dial-up 

Interface 




Modem 



Figure 2: Block diagram of a satellite terminal 



4.3 Network topology 



The satellite terminal network topology will consist of a satellite and dial-up interface. The satellite interface will 
emulate a network adapter with a unique IP address assigned by the Satellite Network. The dial-up connection will be to 
an ISP and with a unique IP address assigned by ISP. The ISP is not aware of the Satellite Network and the return 
channel is to the Internet (not necessarily back to the Satellite Network Operator). The dashed (red) line in the figure 
below shows the signalling path for DVB-S2 ACM command. The S2 Uplink Station is as defined in figure 1. 
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Figure 3: Network topology of a DVB-S2 ACM hybrid satellite dialup system 

This network topology introduces two physical layers both using the same upper layer. This introduces issues related to 
timing of message delivery, often referred to as race conditions. ACM control messages and traffic delivery need to be 
synchronized for transparent traffic delivery to not affect TCP/IP performance. 



5 Protocol stack 

5.1 Session control signalling 

Session control protocols are normatively required in terminals for DVB-S2 ACM interactive services. 
The subset of messages required is as follows: 
Session sequence: 

ACM_RQ/ACM_ACK 
For implementation of session control signalling see clause Session Control in DVB-S2 ACM interactive services. 



5.1.1 ACM_RQ 

The Satellite Terminal will send this message whenever the CNI values do not match the thresholds listed in the ACM 
Capabilities List ( ACM_C AP) . 

Return channel: 

A terminal sends this message over the dial-up connection to the hub station. The message is contained in the payload 
of a UDP datagram as described in table 1 . 

Table 1 : Session control via dialup connection 



UDP 



IP 



PPP(MP) 
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Table 2: Protocol structure of ACM RQ 



MAC Address 


48 


Uimsbf 


Timestamp 


32 


Uimsbf 


passwordjength 


16 


Uimsbf 


for (i=0;i<password_length;i++) { 






Password 


8 


Uimsbf 


} 






MODCOD RQ 


8 


Uimsbf 


CNI 


8 


Uimsbf 


ACM_ACK_MODE 


8 


Uimsbf 



MAC_Address of the DVB-S2 receiver is defined as per IEEE 802.3 [4]. 

Timestamp is a time identifier within the User PC. 

passwordjength is defined as the number bytes the password is maximum of 16 384 Bytes. If zero, no password 
authentication is present. 

Password is defined as a method to authenticate a message at the hub station. The actual method of authentication is 
open to manufacturer of hub stations and terminals implementing DVB-S2 ACM. 

MODCOD_RQ is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) 
of the DVB-S2 system standards [1]. 

CNI is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) of the 
DVB-S2 system standards [1]. 

ACM_ACK_MODE is defined on how the hub is to process and reply to this ACM_REQ. 

Table 3: ACM_ACK_MODE type 



Value 


ACM ACK 
category 


Meaning of ACM_ACK MODE 





NONE 


NO ACM ACK is sent 


1 


FLMPEGPS 


ACM_ACK sent in the forward link using the MPEG Private 
Sections for real-time processing 


2 


FLIP 


ACM_ACK sent in the forward link using UDP 


3 


RCIP 


ACM_ACK sent in the return channel using UDP 



5.1.2 ACM_ACK 

This is a response from the ACM_RQ message. This message is required when more than one input stream is used in 
the system. 

There are two options for sending the ACM_ACK message. 

Satellite Link: 

The hub station will send the ACM_ACK message over the satellite link when the last IP datagram has been transmitted 
on the "old" MODCOD. 

Table 4: DVB-S2 ACM_ACK via satellite link with MPEG private section 



MPEG2 Private Section 



MPEG2 TS 



The DVB-S2 ACM ACK table consists of sections called dvb_s2_acm_ack_section(), which are private sections as 
defined in the MPEG-2 Systems standard (see ISO/IEC 13818-1 [3]). 
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Syntax 


No. of bits 


Mnemonic 


Dvb s2 acm ack section(){ 






table id 


8 


Uimsbf 


Section_syntax_indicator 


1 


Bslbf 


Private indicator 


1 


Bslbf 


Reserved 


2 


Bslbf 


Sectionjength 


12 


Uimsbf 


MAC address 6 


8 


Uimsbf 


MAC address 5 


8 


Uimsbf 


Reserved 


2 


Bslbf 


MODCOD ACK 


8 


Uimsbf 


lnput_Stream_ldentifier 


8 


Bslbf 


Reserved 


8 


Uimsbf 


MAC address 4 


8 


Uimsbf 


MAC address 3 


8 


Uimsbf 


MAC address 2 


8 


Uimsbf 


MAC address 1 


8 


Uimsbf 


replyjen 


16 


Uimsbf 


for(i=0;i< reply_len;i++) { 






Reply 


8 


Uimsbf 


} 






Timestamp 


32 


Uimsbf 


Checksum 


32 


Uimsbf 


} 







table_id is set to 0x81 

section_syntax_indicator is set to "0". 

private_indicator is set to "0". 

sectionjength specifies the number of remaining bytes in the section immediately following the private_section_length 
field. The value must not exceed 4 093. 

MAC_address_[1..6]: This 48-bit field contains the MAC address of the destination. The MAC address is fragmented 
in 6 fields of 8-bits, labelled MAC_address_l to MAC_address_6. The MAC_address_l field contains the most 
significant byte of the MAC address, while MAC_address_6 contains the least significant byte. 

NOTE: The order of the bits in the bytes is not reversed and that the Most Significant Bit (MSB) of each byte is 
still transmitted first. 

MODCOD_ACK is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) 
of the DVB-S2 system standards [1]. 

Input_Stream_Identifier (ISI) in the BBHeader as defined in the DVB-S2 system standards [1] for the resulting 
PLFrame to be demodulated. 

replyjen is defined as the number bytes the reply is maximum of 16 384 Bytes. If zero, no password authentication is 
present. 

Reply is defined as a method to send a message to the terminal for interpretation by the hub station. The actual method 
of reply is open to manufacturer of hub stations and terminals implementing DVB-S2 ACM. 

Timestamp is the time to switch to this MODCOD/ISI. 

Checksum is the checksum of the entire message as defined in the DSM-CC standard [7]. 

Return channel: 

The hub station sends this message over the dial-up connection to the Satellite Terminal. This message will be sent 
when traffic is interrupted for a TBD period of time. The message is contained in the payload of a UDP datagram as 
described in table 1 . 
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Table 5: Protocol structure of ACM ACK 



MODCOD ACK 


8 


Uimsbf 


lnput_Stream_ldentifier 


8 


Uimsbf 


replyjen 


16 


Uimsbf 


for (i=0; i<reply_len;i++) { 






Reply 


8 


Uimsbf 


} 






Timestamp 


32 


Uimsbf 



MODCOD_ACK is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) 
of the DVB-S2 system standards [1]. 

Input_Stream_Identifier in the BBHeader as defined in the DVB-S2 system standards [1] for the resulting PLFrame 
to be demodulated. 

replyjen is defined as the number bytes the reply is maximum of 2 4 Bytes. If zero, no password authentication is 
present. 

Reply is defined as a method to send a message to the terminal for interpretation by the hub station. The actual method 
of reply is open to manufacturer of hub stations and terminals implementing DVB-S2 ACM. 

Timestamp is the time to switch to this MODCOD/ISI. 

5.2 DVB-S2 ACM MODCOD capability transfer 

The hub station stores a list that maps each MODCOD to thresholds and a magic_number used for authentication of the 
return channel request for new MODCOD. It creates the DVB-S2 ACM Capabilities table from this list. It transmits this 
table repeatedly and creates a new version when the content has changed. 

The subset of messages required is as follows: 

Session sequence: 

ACM CAP 



5.2.1 ACM_CAP 

This message is read at start-up and whenever the version number changes. 
Satellite link: Two categories are provided: 

(i) Definition of a MPEG2 private section table across the satellite link. 

Table 6: DVB-S2 MODCOD via satellite link with private sections 



MPEG2 Private Section 



MPEG2 TS 



The DVB-S2 ACM Capabilities table consists of sections called dvb_s2_acm_capabilities_section(), which are private 
sections as defined in the MPEG-2 Systems standard (see ISO/IEC 13818-1 [3]). 
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Syntax 


No. of bits 


Mnemonic 


dvb s2 acm capabilities section(){ 






table id 


8 


Uimsbf 


Section_syntax_indicator 


1 


Bslbf 


Private indicator 


1 


Bslbf 


Reserved 


2 


Bslbf 


Sectionjength 


12 


Uimsbf 


table id extension 


16 


Uimsbf 


Reserved 


2 


Bslbf 


Version number 


5 


Uimsbf 


current next indicator 


1 


Bslbf 


Section number 


8 


Uimsbf 


last section number 


8 


Uimsbf 


number_stream_inputs 


8 


Uimsbf 


modcod_available_length 


8 


Uimsbf 


for (i=0; i<modcod available length; i++) { 






MODCOD 


8 


Uimsbf 


lower CNI threshold 


8 


Uimsbf 


upper CNI threshold 


8 


Uimsbf 


} 






Magic_number 


32 


Uimsbf 


lp_router_ipaddress 


32 


Uimsbf 


lp_router_portnumber 


16 


Uimsbf 


CRC 32 


32 


Rpchof 


} 







table_id is set to 0x80. 

section_syntax_indicator is set to " 1 " . 

private_indicator is set to "0". 

sectionjength specifies the number of remaining bytes in the section immediately following the private_section_length 
field. The value must not exceed 4 093. 

table_id_extension is reserved. 

version_number, current_next_indicator, section_number, last_section_number, CRC_32 as defined for private 
sections in ISO/IEC 13818-1 [3]. 

number_stream_inputs indicates if a single or multiple input stream. " 1 " indicates one input stream, any other number 
indicates multiple inputs streams in the system. See annex B for an explanation. 

modcod_available_length is the number of MODCODs available on this network. 

MODCOD is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) of the 
DVB-S2 system standards [1]. 

lower_CNI_threshold is the recommended value for minimum signal to noise measurements before moving down to 
the next MODCOD. 

upper_CNI_threshold is the recommended value for maximum signal to noise measurements before moving up to the 
next MODCOD. 

magic_number is used in the UDP/IP ACM_RQ for packet authentication sent to the hub station. 

ip_router_ipaddress is the IP address of the IP router. 

ip_router_portnumber is the IP port number of the IP router. 

(ii) Definition of a Multicast message across the Satellite Link. 
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Table 7: Multicast via satellite link 



MULTICAST 



IP 



Datalink Layer 



MPEG2 TS 



Version number 


4 


uimsbf 


number_stream_inputs 


8 


uimsbf 


Modcod_available_length 


4 


uimsbf 


for (i=0; i< modcod available length; i++) { 






MODCOD 


8 


uimsbf 


lower CNI threshold 


8 


uimsbf 


upper CNI threshold 


8 


uimsbf 


} 






Magic_number 


32 


uimsbf 


lp_router_ipaddress 


32 


uimsbf 


lp_router_portnumber 


16 


uimsbf 



version_number indicates the current version of this information. All information needs to be updated in the terminal 
when it is detected this value has changed. 

number_stream_inputs indicates if a single or multiple input stream. " 1 " indicates one input stream, any other number 
indicates multiple inputs streams in the system. See annex B for an explanation. 

modcod_available_length is the number of MODCODs available on this network. 

MODCOD is defined in the sections for Signalling of reception quality via return channel (Normative for ACM) of the 
DVB-S2 system standards [1]. 

lower_CNI_threshold is the recommended value for minimum signal to noise measurements before moving down to 
the next MODCOD. 

upper_CNI_threshold is the recommended value for maximum signal to noise measurements before moving up to the 
next MODCOD. 

magic_number is used in the UDP/IP ACM_RQ for packet authentication sent to the hub station. 

ip_router_ipaddress is the IP address of the IP router. 

ip_router_portnumber is the IP port number of the IP router. 



Session control in DVB-S2 ACM interactive services 



6.1 



Introduction 



Connection-less session control is needed to provide the service of informing the terminal of the MODCODs available 
and the terminal requesting from the hub station an appropriate MODCOD for its given Signal to Noise measurements. 

All basic message flows are identical where establishing a session, changing the MODCOD due to changing CNI 
values, and the loss of messages. 

Shown is two figures, one where the ACM_CAP and ACM_ACK messages use DVB -Private Sections in the Forward 
Link for multiple input streams and the other the ACM_CAP in the Forward Link IP Layer and ACM_ACK in the 
return channel IP layer. 

In all both instances the ACM_RQ is sent in the return channel. 

The Satellite Terminal will need to be configured for the method of finding the ACM_CAP message via PID or PID and 
Multicast IP address. 
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6.1 .1 ACM messaging Using DVB private sections 

The ACM_CAP and ACM_ACK message is done at the DVB Private Section level so that the Receiver can process the 
information in real-time with minimum interaction with the User PC and Modem. This reduces timing issues and can 
centralize all functionality in the Receiver. 

The ACM_ACK is required for systems using multiple input streams and optional otherwise. 



HUB 



Receiver 



User PC 



Modem 



Forward Link ACM CAP 



RCSendACK FfeQ 



RC Send 



RC Send ACM RQ 



Forward LinkACM_ACK 
__ (OPTIONAL) 



ACK RQ 



Figure 4: Message sequence using DVB private sections to deliver the ACM_CAP and ACM_REQ 
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6.1 .2 ACM messaging multicast and dial-up session control 

The ACM_CAP and ACM_ACK are sent via the IP layer. This requires the system to be of a single input stream and 
that the ACM_ACK is not required to be processed in real-time. The ACM_ACK is optional in this instance. 



HUB 



Receiver 



User PC 



Multicast ACM CAP 



Modem 



Multicast ACM CAP 



CNI 



RC Send 



RC Send ACM RQ 



RCIPACM_ACK* 
RC 
ACM AGK 



IP 



ACK RQ 



ACM_ACK* 
Command* 



NOTE: Those messages with an "*" are optional. 

Figure 5: Message sequence using the IP layer to deliver the ACMCAP in the forward link and 

ACM ACK/ ACM REQ in the return channel 



6.2 



Session Establishment 



This connection-less session is established by the act of the Satellite Terminal reading data off the Satellite Link via a 
table or multicast message that consists of the MODCODs in the system, Signal to noise thresholds for choosing a 
MODCOD, and a "magic_number" for MODCOD message authentication (ACM_CAP message). Additional contact 
information will be provided. This information needs to updated for every version number change. 

The magic_number, IP and port number should change periodically for security reasons. Authentication of the 
ACM_RQ is recommended and implementation is not defined here. 

An ACM_RQ will be sent to request the correct MODCOD for the given measurements and thresholds listed. 

Once the ACM_RQ is sent the terminal can wait for an ACM_ACK or demodulate everything it can. With multiple 
input streams, the ACM_ACK is required to configure the Receiver to de-capsulate the correct ISI. 
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6.3 Client initiated session reset 

The terminal at any time may send an ACM_RQ whenever CNI changes enough to warrant moving to a more 
appropriate modulation and/or forward error correction. 

This flow can also be initiated if the Satellite Terminal suspects message loss. 

This CNI is measured and the thresholds to change to are in the ACM_CAP message. Once the ACM_RQ is sent, the 
terminal can wait for an ACM_ACK or demodulate everything it can. With multiple input streams, the ACM_ACK is 
required to configure the Receiver to demodulate the correct MODCOD and ISI. 

Authentication of the ACM_RQ is recommended and implementation is not defined here. 
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Annex A (informative): 
Assumptions for hub station 



ACM commands are primarily for the switching of IP traffic from one MODCOD to another. The traffic has to be 
moved based on the IP destination or MAC Address of the terminal. Modulators are thus assumed to have an internal 
mechanism for moving data identified in a MODCOD_RQ. This could be envisioned by having a three pieces of 
information on each piece of data: MODCOD, destination, and counter. The MODCOD and destination are obvious 
with the counter being used for tracking the order of the data pieces. 

Systems with multiple input streams each having a unique ISI code will need to find a clean mechanism of timing 
between the hub station and terminal. This timing is needed coordinate the switching of ISI codes without traffic 
interruption. 

The hub station will prevent a race condition for arrival of data affected by an ACM command. This situation is 
aggravated by having signalling at the IP layer via the physical layer and then this signalling needs to be re-directed 
back to the terminal for processing. This creates a virtual queue in the system that IP data packets arrive after the ACM 
command is received and processed before the ACM command takes affect. 
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Annex B (informative): 
Input Streams Defined 



In a DVB-S2 standard [1] three general types of implementation are possible for interactive services for BBHeader 
coding. 
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Figure B.1 : Stream format at the output of the Mode Adapter 

In this figure from the DVB-S2 standard [1] the packetized stream data is not split on the User Packet (UP) boundaries. 
This functionality requires the BBFrames be ordered or sortable at the de-modulator to re-construct the UP correctly. 



B.1 Single Input Stream 



The order of these UP is preserved PLFrame to PLFrame independent of the ISI value. This mean the demodulator 
either has to sort by ISI or rely on the DVB-S2 modulator to guarantee that a split UP packet always starts on the next 
BBFrame data field. Thus BBFrame with ISI value 5 could end with a partial data segment and continues when the next 
BB Frame transmitted with a different ISI value. 



B.2 Multiple Input Stream 



The order of these UP is preserved PLFrame to PLFrame by ISI value. The order of the data is preserved by 
demodulation of a specific ISI values. Thus BBFrame with ISI value 5 could end with a partial data segment and only 
continues when the next BBFrame with ISI value 5. 
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Annex C (informative): 
SI and PSI 

C.1 General 

MPEG Program Specific Information and (PSI) and DVB Service Information (SI) enables DVB to locate and select the 
data that belongs to a particular program or service on a network. In the kind of networks considered in the present 
document, PSI and SI enables a terminal to locate and select the Internet Protocol data it shall receive, together with the 
signalling for ACM. 

The DVB-S2 standard [1] defines in table D.4.1 three configurations for interactive services with ACM: 

• Multiple Transport Streams. 

• Multiple Generic Streams. 

• Single Generic Stream. 

In the following, use of PSI and SI is described for the three configurations. 



C.2 Multiple Transport Streams 



In the case of Multiple Transport Streams, IP datagrams are encapsulated into the MPEG Transport Streams (TS) by 
DVB Multiprotocol Encapsulation (DVB-MPE), which is defined in the DVB Data Broadcast standard (see 
EN 301 192 [6]). On each TS, a single program in the MPEG sense (or service) is sufficient. In a simple case, the 
program contains a single DVB-MPE stream. In addition, the program must contain the DVB-S2 ACM ACK Table and 
the DVB-S2 ACM ACK Capabilities Table. It is assumed that sections of these two tables can be carried in the same 
Private Section stream. 

For compliance with the MPEG-2 Systems standard (see ISO/IEC 13818-1 [3]), any TS contains a PAT, and a PMT for 
each program. In DVB-S2 ACM sat/terrestrial networks, the TS contains one PMT for the single program. The PMT 
contains information about the DVB-MPE stream and the Private Section stream. For compliance with the DVB -SI 
standard (see EN 300 468 [2]), any TS contains a NIT, which contains tuning parameters for the TS in a network. For In 
DVB-S2 ACM sat/terrestrial networks it is assumed that the NIT contains at least the TS with most robust MODCOD 
on every DVB-S2 carrier. 

A terminal that shall use a DVB-S2 ACM sat/terrestrial network needs to know the transport_stream_id of the most 
robust MODCOD. With this transport_stream_id given, it accesses the IP data and control by the following steps: 

1) Tune to any transponder. In the case of a DVB-S2 transponder, select any TS on it. 

2) Read the NIT from TS packets with PID = 16. 

3) Derive from NIT the tuning parameters and ISI for the given transport_stream_id. 

4) Tune to the transponder that carries the TS with given transport_stream_id. 

5) Select the ISI that carries the TS with given transport_stream_id. 

6) Read the PAT from TS packets with PID = 0. 

7) Derive from PAT the PID value of the single PMT. 

8) Read the PMT. 

9) Derive from PMT the PID value of the stream with stream type 14. This is the DVB-MPE stream. 

10) Derive from PMT the PID value of the stream with stream type 5. This is the stream that contains the S2 ACM 
ACK Table and the DVB-S2 ACM ACK Capabilities Table. 
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11) Select continuously from the DVB-MPE stream the sections that contain the own MAC address. De-capsulate 
IP datagrams and process them. 

12) Read the DVB-S2 ACM ACK Capabilities Table and observe continuously whether a different MODCOD is 
required. 

13) If a MODCOD change is required, then continue with the following steps. 

14) Request the MODCOD change through the return channel (dial-up connection). 

15) Read continuously the S2 ACM ACK Table until it contains an acknowledgement for the requested 
MODCOD change. 

16) Select the TS with the ISI that is contained in the acknowledgement. 

17) Go back to step 7). 



C.3 Multiple Generic Streams 



In the case of Multiple Generic Streams (GS), a specification for encapsulating IP datagrams on a DVB-S2 GS is 
required. A DVB specification for this kind of encapsulation was not yet available when the present document has been 
finalized. If a future specification allows to transmit MPEG private sections in addition to encapsulated IP datagrams on 
the same GS, then PSI and SI can be used in a similar way as described above for multiple 
Generic Streams. 

A possible encapsulation uses a structure similar to a TS, but without the requirement for constant bit rate. 



C.4 Single Generic Stream 



In the case of Single Generic Stream, a specification for encapsulating IP datagrams on a DVB-S2 GS is required, like 
for the case of Multiple Generic Streams. 

It is not necessary to transmit an acknowledgement on the satellite forward link. The DVB-S2 ACM MODCOD 
Capability transfer can be done by IP multicast. Therefore, no private section transmission is required. 

A possible encapsulation must tolerate that a particular terminal does not receive those parts of the stream that are 
transmitted with a less robust MODCOD. 
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